Configure the audio session before recording starts, not only on connect - #1179

…pushed (#1182)

## Problem

On iOS the WebRTC audio engine refuses to enable recording unless the
audio session category permits input. Its pre-enable check returns
`kAudioEngineErrorAudioSessionInvalidCategory` (-9001), which the SDK
reported as `AudioProcessingException(applyFailed): Audio engine
returned error code: -9001`.

`livekit_client` owns the iOS audio session since #1108
(`LiveKitPlugin.swift` disables flutter_webrtc's session management at
registration). The native engine observer
(`LKAudioEngineObserver.willEnableEngine`) is the right hook and runs
before the engine's check, but it only applied a configuration that Dart
had pushed. In automatic mode the only push site was `Room.connect`, so
anything that started recording earlier met an empty cache, the observer
returned "proceed" with the session still `soloAmbient`, and the engine
rolled back:

- `Room.withPreConnectAudio`, which `SessionOptions.preConnectAudio`
enables by default, so the Flutter agent starter failed on every "Start
call"
- a pre-join microphone preview (#1165)
- an engine start driven from native before the Flutter side exists, for
example the plugin's static `setEngineAvailability` on a CallKit
killed-state wake

Because the preconnect throw happens before `connect`, the cache was
never seeded and the failure repeated on every attempt.

## How the Swift SDK handles this

`AudioSessionEngineObserver.engineWillEnable` derives the session
configuration from the requested engine state alone (`playAndRecord`
presets while recording, `playback` for playout only), synchronously
inside the engine's enable call. Nothing is configured "before connect".
The engine asks, the observer configures, the engine starts. The Flutter
plugin already has the same observer in the same place, it just had no
built-in policy.

## Fix

`LKAudioEngineObserver.effectiveConfigurationLocked` now resolves a
built-in `playAndRecord` preset (`allowBluetooth | allowBluetoothA2DP |
allowAirPlay`, `videoChat`) whenever nothing has been pushed and
automatic management is on. The existing playout-only `playback` branch
applies to it as well. Manual mode still leaves the session alone. The
Dart-pushed policy becomes an override rather than a prerequisite, and
for the default `AudioSessionOptions.communication` it pushes the same
values, so the connect-time push does not change the live session.

The preset is built on a copy of the shared
`RTCAudioSessionConfiguration.webRTC()` object, and it is best-effort:
if applying it fails, the engine start proceeds and the ADM's own
pre-enable checks still gate recording, so apps whose own session was
already valid are not newly rolled back with -4100. Only a policy the
app actually pushed keeps failing the engine start hard. The mode is
fixed to `videoChat` because it matches the Dart default speaker
preference, and a non-default preference always arrives as a pushed
policy whose mode already carries it, so the preset can never observe
anything else.

`LocalAudioTrack.startCapture` additionally pushes the resolved Dart
policy to native before recording starts (cache-only while the engine is
idle in automatic mode). Flutter-driven starts therefore always use the
real Dart policy, and the built-in preset only stands in for engine
starts that happen before the Flutter side exists, for example the
plugin's static `setEngineAvailability` on a CallKit killed-state wake.

The engine observer is also shared across plugin registrations now: a
second Flutter engine registering in the same process (add-to-app,
`FlutterEngineGroup`) previously reset the pushed policy and management
mode silently, which the preset would have turned into an unwanted
session activation. Only the notification channel is rebound per
registration.

## Error mapping

Audio device module results now get their own error codes on the
`startLocalRecording`, `setEngineAvailability`, `setMicrophoneMuteMode`
and `stopLocalRecording` channels, mirroring client-sdk-swift's
`checkAdmResult`. A mute-mode change can rebuild the engine and hit the
same pre-enable checks as a recording start, so all entry points surface
the same failure the same way:

| ADM result | Native error code | Dart exception |
| --- | --- | --- |
| -9000 `InsufficientDevicePermission` | `deviceAccessDenied` |
`TrackCreateException` |
| -9001 `AudioSessionInvalidCategory` | `audioSessionInvalidCategory` |
`AudioSessionException` (new) |
| -4100 `FailedToConfigureAudioSession` | `audioSessionConfigureFailed`
| `AudioSessionException` (new) |
| anything else | caller fallback (`applyFailed`,
`setEngineAvailability`, ...) | unchanged |

`AudioSessionException` is a new public class with its own changeset
entry.

## Relation to #1179

@MaxHeimbrock's #1179 diagnosed this first and fixes it by pushing the
policy from `LocalAudioTrack.startCapture` (`prepareRecording()`). This
PR ends up covering both layers: `startCapture` pushes the resolved
policy like #1179 does (without a Dart-side flag tracking native cache
state), and the native observer is additionally self-sufficient like
Swift's, so engine enables that never pass through Dart are covered too.
With this merged, `prepareRecording()` becomes redundant.

## Testing

- Flutter agent starter on an iPhone 17 Pro (iOS 27.0): unpatched,
`Start call` failed with -9001 on every attempt. Patched,
`startCapture()` succeeds two seconds before the connect-time policy
push, the preconnect buffer is sent to the agent, and the call connects.
- `flutter analyze`, `flutter test`, `dart format
--set-exit-if-changed`, `import_sorter --exit-if-changed` clean.
- New unit tests cover the error mapping. The iOS-gated branches are not
reachable from unit tests (`lkPlatform()` has no seam), same limitation
as #1179 noted.

Fixes #1165
Refs #1042